\chapter{Huidige technieken}
\label{HuidigeTechnieken}
Een web mashup bestaat uit een of meerdere third party componenten. 
Deze componenten moeten ge\"integreerd worden in de pagina door een integrator. 
Hiervoor moet de integrator de nodige glue code voorzien. 
In dit hoofdstuk beschrijven we enkele technieken die gebruikt kunnen worden voor het integreren van deze third party componenten in een web mashup.

\section{Current state of practice}
\label{curstateofprac}
Onder current state of practice verstaan we de technieken die reeds aanwezig zijn in de browser. 
De twee technieken die hier onder vallen zijn script inclusion en iframe integration.
\subsection{Script inclusion}
HTML \lstinline|script|-tags kunnen worden gebruikt om JavaScript te laten uitvoeren tijdens het laden van de webpagina. 
Deze code kan afkomstig zijn van een andere server dan de server die de webpagina inlaadt \textit{(pagina van integrator)}.
Toch zal de browser de code uitvoeren alsof het van dezelfde origin afkomstig is dan de code van de integrator zelf, 
zonder enige beperking van de same-origin policy. De ge\"integreerde code zal uitgevoerd worden in dezelfde JavaScript context,
d.w.z. toegang krijgen tot de volledige inhoud van de webpagina waarin het wordt uitgevoerd. 
Alle gevoelige JavaScript functionaliteiten die toegankelijk zijn voor de pagina waarin de code uitgevoerd wordt,
zullen ook toegankelijk zijn voor de ge\"integreerde code.

\subsection{IFrame integration}
HTML \lstinline|iframe|-tags kunnen worden gebruikt om een pagina in te laden in een andere frame. 
De ge\"integreerde pagina wordt in zijn eigen omgeving ingeladen net alsof het in een apart browser window geladen zou worden.
Daardoor zullen de ge\"integreerde componenten met verschillende origines ge\"isoleerd zijn van elkaar dankzij de same-origin policy. 
Wel zal code die in een frame uitgevoerd wordt nog steeds alle gevoelige JavaScript functionaliteiten ter beschikking hebben.
Ook al zijn ze beperkt tot hun eigen context. Een third party component zou bijvoorbeeld gebruik kunnen maken van de \lstinline|localStorage| API,
maar zal enkel toegang hebben tot de \lstinline|localStorage| van zijn eigen origine.

\subsection{Voor- en nadelen}
Het belangrijkste voordeel van deze technieken is dat ze makkelijk te gebruiken zijn.

Op zich lijkt iframe integration een goed beveiligingsconcept, omdat het de componenten scheidt via de same-origin policy. 
Zoals reeds aangehaald is dit niet voldoende, zeker door de nieuwe HTML5 specificaties.
Er is nood aan een least-privilege concept en dit is niet mogelijk door middel van deze twee technieken.
Geen van onze doelstellingen kunnen met deze technieken bereikt worden.

\section{Current state of the art}
Als belangrijkste stuk van de literatuurstudie, hebben we gekeken naar bestaande technieken. Er zijn al heel wat technieken beschreven die onze probleemstelling proberen op te lossen. 
Toch is het zo dat elk van deze nog zijn beperkingen heeft. In deze sectie beschrijven we enkele van deze technieken en zoomen voor elk van deze in op een implementatie.

\subsection{JavaScript Subsets}
Er zijn al nieuwere technieken ontwikkeld waarmee er wel op een veilige manier externe componenten kunnen ge\"integreerd worden.
Deze technieken maken gebruik van de interactie mogelijkheden in de omgeving van de scripts, en proberen een scheiding te introduceren tussen de verschillende componenten.
Ze doen dit door JavaScript te beperken tot een subset, gebruikmakend van het object-capability beveiligingsmodel.
Dit model is gebaseerd op het feit dat gescheiden objecten geen mogelijkheden hebben en enkel mogelijkheden van een object kunnen verwerven als ze een referentie krijgen naar dat object.
Bijvoorbeeld als het object geen referentie naar het  \lstinline|XMLHttpRequest| object heeft, zal er ook geen instantie van kunnen aangemaakt worden.
Door een referentie aan het object toe te voegen, krijgt het wel de mogelijkheid om met  \lstinline|XHR| requests te sturen.

Er is reeds veel werk\cite{caja}\cite{fbjs}\cite{adsafety}\cite{gatekeeper} verricht rond het beperken van functionaliteiten en het afdwingen van policies met deze methode.
In deze sectie lichten we kort Caja en FBJS toe. Een voorbeeld van hoe zo'n herschreven code er uitziet, is te zien in tabel \ref{subsetExample}.

\subsubsection{Caja}
Caja\cite{caja} is een veilige JavaScript subset gemaakt door Google.
Het analyseert JavaScript code en herschrijft de code tot ge\"isoleerde modules.
CaJa doet meer dan alleen het omvormen tot een subset. Het introduceert ook een nieuwe feature: frozen objects.
Deze $"$bevroren$"$ objecten kunnen niet worden aangepast, waardoor ze geschikt zijn om informatie te delen tussen verschillende componenten.
Objecten in de global scope zijn automatisch bevroren.
Caja laat wel bepaalde onveilige functionaliteiten\cite{cajalimit} niet toe zoals  \lstinline|eval| en  \lstinline|iframe|, 
ook het gebruik van \lstinline|this| is gelimiteerd omdat het properties heeft die referenties naar het global object kunnen lekken (met de referenties naar de originele functies).
Caja laat wel toe dynamisch content toe te voegen, deze wordt dan op de server herschreven tot de veilige subset. Dit proces noemt men $"$cajolen$"$.
Hiermee verzekeren ze de doorlopende bescherming.

Volgens het object-capability model kunnen de componenten enkel nog communiceren via de expliciet gedeelde objecten.
Deze objecten moeten betrouwbaarheid en integriteit aanbieden. 
Onderzoek heeft aangetoond dat de beveiliging van JavaScript subsets met Caja veilig is\cite{cajasafe}. 
Dit belangrijk resultaat laat zien dat JavaScript subsets met object-capabilities kunnen voldoen aan de voorgestelde security requirements.

\subsubsection{FBJS}
FBJS of Facebook JavaScript \cite{fbjs} is een techniek dat door facebook gebruik wordt om Facebook apps op een veilige manier te integreren, deze is ondertussen wel achterhaald
en vervangen door een techniek dat minder relevant is voor onze thesis. FBJS is een variant van JavaScript dat heel sterk op JavaScript lijkt, de syntax is volledig hetzelfde
maar sommige functies zijn aangepast. Zo is de DOM vervangen door FB DOM dat een veiligere variant is van de DOM.
Ook zal de applicatie id voor alle namen (variabelen en functies) in de FBJS code automatisch geplaatst worden.
Hierdoor zal iedere applicatie binnen zijn eigen virtuele scope draaien. 
Ook FBJS heeft een actief beschermingsmechanisme dat toe laat dynamisch inhoud toe te voegen.
Een nadeel hier is dat elke request door de Facebook servers moet gaan, wat niet voor elke integrator haalbaar is.

\begin{table}
\centering
	\begin{tabular}{l c r}
	 
		\hline
		Caja 		& : &	 \lstinline|$v.r($v.ro('obj'),$v.ro('name'))|	\\
		FBJS 		& : &	 \lstinline|a12345_obj[$FBJS.idx(name)]|	\\
		ADSAFE 	& : &	 \lstinline|ADSAFE.get(obj,name)|		\\
		\hline
	\end{tabular}
	\caption{Voorbeeld subset: syntax  \lstinline|obj[name]| na herwerking}
	\label{subsetExample}
\end{table}

\subsubsection{Voor- en nadelen}
Het grootste voordeel van deze technieken is dat ze voor de client onzichtbaar zijn. Een gebruiker moet bijvoorbeeld ook geen aangepaste versie van de browser installeren.
Zoals vermeld is het ook bewezen dat Caja veilig is, wat een mooie bijdrage is voor deze methode. De beperkingen kunnen opgelegd worden aan de hand van policies

Het nadeel is dat legacy componenten meestal niet kunnen gebruikt worden met deze technieken omdat ze sommige JavaScript functionaliteiten niet ondersteunen.
Componenten die wel gebruik maken \lstinline|eval|,  \lstinline|with|, etc., zullen moeten herwerkt worden om compatibel te zijn met deze technieken.
Hierdoor kan met deze techniek enkel doelstelling D2 niet behaald worden.


\subsection{Aanpassingen in de browser}
Er zijn ook nog andere technieken\cite{conscript}\cite{webjail}, die gebruik maken van een andere opstelling. Hier hoeft er geen code herschreven te worden. Deze technieken zijn rechtstreeks in de
browser ingebouwd en maken het mogelijk om policies toe te passen op JavaScript code.

\subsubsection{Conscript}
Conscript \cite{conscript} laat toe de integrator een policy aan een ge\"integreerde component op te leggen. Deze policies bestaan uit 
JavaScript code dat meegegeven wordt aan de script tag via het nieuwe \textit{POLICY}-attribuut. De policy staat toe om functies op zeer specifieke
 manieren af te schermen. Ze schermen alle paden naar functies af door gebruik te maken van \textit{deep aspects}.
\subsubsection{Webjail}
Webjail \cite{webjail} is gebaseerd op Conscript en staat toe om componenten op een least-privilege manier te integreren
door policies toe te passen op code die uitgevoerd wordt binnen een iframe. 
De policy wordt in JSON formaat aan de iframe tag toegevoegd via het nieuwe \textit{POLICY}-attribuut.
\pagebreak
\subsubsection{Voor- en nadelen}
\label{browserupdAdv}
Omdat deze technieken rechtstreeks in de browser ge\"implementeerd worden is het bij deze technieken makkelijker om sommige problematische JavaScript functionaliteiten toch te ondersteunen. 
Ook kunnen ze meestal op een effici\"ente manier ge\"implementeerd worden. 

Maar omdat de browser aangepast is, zal een client enkel beschermd worden als hij zelf gebruik maakt van deze aangepaste browser. Enerzijds kunnen we dit niet verwachten van gebruikers, anderzijds zijn veel gebruikers ook niet met hun veiligheid bezig.
Hierdoor is ook dit een ernstig nadeel en wordt niet voldaan aan doelstelling D4.

\subsection{Afschermen van JavaScript features aan de client kant}
Deze aanpak is ook met Conscript en Webjail te vergelijken. Bij het oproepen van een JavaScript functie zal er eigenlijk de functie opgeroepen worden die rond de oorspronkelijke functie geweven zit. 
Binnen deze functie zit er een check die nagaat of de functie wel mag uitgevoerd worden. 
Deze check maakt gebruik van een Policy die beschreven kan worden door de integrator. Dit is eigenlijk ook precies wat Conscript doet. 
Het verschil is dat deze aanpak onafhankelijk is van de browser.

\subsubsection{Lightweight Self-Protecting JavaScript}
Lightweight Self-Protecting JavaScript\cite{selfprotectjs} werkt op de voorgestelde manier. 
In plaats van aanpassingen te doen aan de browser en daar functionaliteit te voorzien om policies op te leggen. 
Zal deze aanpak de policies afdwingen door in JavaScript rond de gevoelige functies een nieuwe functie te defini\"eren. 
De referentie naar de originele functie wordt verstopt, en wanneer men deze probeert op te roepen, zal de wrapper functie opgeroepen worden. 
De JavaScript code die hiervoor zorgt wordt meegestuurd en uitgevoerd in de browser.
Dit moet gebeuren voor er code van de externe componenten kan uitgevoerd worden.

\subsubsection{Voor- en nadelen}
Deze methode combineert de voordelen van de 2 voorgaande al reeds. Er zijn geen browser aanpassingen nodig en er is ook meer compabiliteit met bestaande code.
\lstinline|this| en \lstinline|with| kunnen bijvoorbeeld wel ondersteund worden.

Met deze aanpak is het moeilijk een correcte beveiliging af te dwingen. Het verstoppen van de originele functies is bijvoorbeeld niet zo evident, 
er zijn bijvoorbeeld meer paden naar eenzelfde functie. Ook kan een hacker er proberen voor te zorgen dat de originele functie terug wordt gezet.
Self-Protecting JavaScript is daardoor nog niet waterdicht. Verschillende van deze problemen zijn reeds ge\"identificeerd,
andere worden nog steeds onderzocht\cite{selfprotectjsIssues}. We stellen dus dat er nog niet kan voldaan worden aan doelstelling D1.

\subsection{Advertenties}
Ook online advertenties kunnen beschouwd worden als web mashups.
Er moeten kleine stukjes externe code worden uitgevoerd om ze te renderen. Op deze manier kunnen er meer gerichte advertenties gegenereerd worden. 
Bijvoorbeeld aan de hand van de interesses van de actieve gebruiker. In deze sectie bespreken we een aantal ontwikkelde technieken die zich specifiek richten op het veilig integreren van online advertenties.

\subsubsection{AdJail}
AdJail\cite{adjail} zal de code van de advertenties eerst uitvoeren in een sandbox, of \emph{shadow page}. 
Daarbij worden de effecten van de advertentie geobserveerd, zodat ze op dezelfde manier doorgevoerd kunnen worden op de pagina volgens een security policy. 
Daarna zullen de gebruikerinteracties met de advertentie (e.g. muisklik) doorgestuurd worden naar de sandbox. 
Dit is onder andere nodig omdat de advertentie het aantal muisklikken moet doorsturen naar de publisher van de advertentie, zodat de host van de advertentie zijn vergoeding kan krijgen. 
De \emph{shadow page} waarin de advertentie uitgevoerd wordt is een verborgen \lstinline|iframe| element dat een andere origin heeft dan de host pagina.
Dit zorgt ervoor dat de host pagina en de advertentie van elkaar afgeschermd zijn.

\subsubsection{AdSentry}
AdSentry\cite{adsentry} werkt op een gelijkaardige manier als AdJail. 
Ook hier zal de advertentie in een sandbox worden uitgevoerd en zullen de effecten van de advertentie doorgevoerd worden aan de pagina volgens een security policy.
AdSentry is verschillend van AdJail in de zin dat de advertenties bij AdSentry in een \emph{shadow JavaScript engine} worden uitgevoerd en niet in een iframe.
Deze engine moet eerst ge\"installeerd worden als browser plugin.

\subsubsection{Voor- en nadelen}
Zoals gezegd worden deze advertenties uitgevoerd in een sandbox omgeving, waar deze geen kwaad kunnen doen aan de hosting pagina. 
Hierdoor voldoen ook deze technieken nog niet volledig aan het mashup model. De advertenties werken op zichzelf, eventueel aangestuurd door de hosting pagina. 
Communicatie tussen de verschillende componenten is hier nog niet mogelijk.